Problembehandlung für den windows Server-Softwaredefinierte Netzwerkstapel

In diesem Leitfaden werden die gängigen SDN-Fehler (Software Defined Networking) und -Fehlerszenarien untersucht. und es wird ein Problembehandlungsworkflow beschrieben, der die verfügbaren Diagnosetools verwendet. Weitere Informationen zu SDN finden Sie unter Software-Defined Networking.

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, Versionen 21H2 und 20H2

Fehlertypen

Die folgende Liste stellt die Klasse der Probleme dar, die am häufigsten bei der Hyper-V-Netzwerkvirtualisierung (HNVv1) in Windows Server 2012 R2 bei marktüblichen Produktionsbereitstellungen auftreten. Dies deckt sich in vielerlei Hinsicht mit den gleichen Arten von Problemen, die bei Windows Server 2016 HNVv2 mit dem neuen SDN)-Stpel(Software-Defined Network) auftreten.

Die meisten Fehler können in eine kleine Gruppe von Klassen eingeordnet werden:

• Ungültige oder nicht unterstützte Konfiguration

  Ein Benutzer ruft die NorthBound-API falsch oder mit ungültiger Richtlinie auf.

• Fehler in der Richtlinienanwendung

  Richtlinie vom Netzwerkcontroller wurde nicht an einen Hyper-V-Host übermittelt, verzögert oder nicht auf dem neuesten Stand auf allen Hyper-V-Hosts (z. B. nach einer Livemigration).

• Konfigurationsabweichung oder Softwarefehler

  Datenpfadprobleme, die zu verworfenen Paketen führen.

• Externer Fehler im Zusammenhang mit NIC-Hardware/Treibern oder der Unterschicht-Netzwerk fabric

  Fehlerhafte Aufgabenausladungen (z. B. VMQ) oder falsch konfiguriertes Netzwerk-Fabric (z. B. MTU)

  Dieser Leitfaden zur Problembehandlung untersucht jede dieser Fehlerkategorien und empfiehlt bewährte Methoden und Diagnosetools, die zur Identifizierung und Behebung des Fehlers verfügbar sind.

Diagnosetools

Bevor wir die Problembehandlungsworkflows für jede dieser Arten von Fehlern besprechen, untersuchen wir die verfügbaren Diagnosetools.

Um die Diagnosetools des Netzwerkcontrollers (Steuerelementpfad) zu verwenden, müssen Sie zuerst das RSAT-NetworkController Feature installieren und das NetworkControllerDiagnostics Modul importieren:

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

Um die Diagnosetools für HNV-Diagnose (Datenpfad) zu verwenden, müssen Sie das HNVDiagnostics-Modul importieren:

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

Netzwerkcontrollerdiagnose

Diese Cmdlets sind auf TechNet im Cmdlet "Netzwerkcontrollerdiagnose" dokumentiert. Sie helfen dabei, Probleme mit der Netzwerkrichtlinienkonsistenz im Steuerungspfad zwischen Netzwerkcontrollerknoten und zwischen dem Netzwerkcontroller und den NC-Host-Agents zu identifizieren, die auf den Hyper-V-Hosts ausgeführt werden.

Die Debug-ServiceFabricNodeStatus Und Get-NetworkControllerReplica Cmdlets müssen von einem der virtuellen Computer des Netzwerkcontrollerknotens ausgeführt werden. Alle anderen NC-Diagnose-Cmdlets können von einem beliebigen Host ausgeführt werden, der über eine Verbindung mit dem Netzwerkcontroller verfügt und sich entweder in der Netzwerkcontrollerverwaltungs-Sicherheitsgruppe (Kerberos) befindet oder Zugriff auf das X.509-Zertifikat zum Verwalten des Netzwerkcontrollers besitzt.

Hyper-V-Hostdiagnose

Diese Cmdlets sind auf TechNet im Hyper-V Network Virtualization (HNV)-Diagnose-Cmdlet dokumentiert. Sie helfen dabei, Probleme im Datenpfad zwischen Mandanteb-VMs (Osten/Westen) und eingehendem Datenverkehr über eine SLB-VIP (Norden/Süden) zu identifizieren.

Die Debug-VirtualMachineQueueOperation, Get-CustomerRoute, Get-PACAMapping, Get-ProviderAddress, Get-VMNetworkAdapterPortId, , Get-VMSwitchExternalPortIdund Test-EncapOverheadSettings sind alle lokalen Tests, die von jedem Hyper-V-Host ausgeführt werden können. Die anderen Cmdlets rufen Datenpfadtests über den Netzwerkcontroller auf und benötigen daher Zugriff auf den Netzwerkcontroller, wie oben beschrieben.

GitHub

Das Microsoft/SDN-GitHub-Repository verfügt über viele Beispielskripts und -workflows, die auf diesen integrierten Cmdlets aufbauen. Insbesondere befinden sich Diagnoseskripts im Ordner Diagnostics. Helfen Sie uns, zu diesen Skripts beizutragen, indem Sie Pull Requests übermitteln.

Behandeln von Workflows und Leitfäden

[Hoster] Überprüfen der Systemintegrität

In mehreren Netzwerkcontrollerressourcen befindet sich eine eingebettete Ressource namens Konfigurationsstatus. Der Konfigurationsstatus enthält Informationen zur Systemintegrität, einschließlich der Konsistenz zwischen der Konfiguration des Netzwerkcontrollers und dem tatsächlichen (ausgeführten) Zustand auf den Hyper-V-Hosts.

Führen Sie den folgenden Befehl von einem beliebigen Hyper-V-Host mit Layer-3-Verbindung zum Netzwerkcontroller aus, um den Konfigurationszustand zu überprüfen.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

Eine Beispielmeldung zum Konfigurationsstatus wird unten gezeigt:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

Die folgende Tabelle zeigt die Liste der Fehlercodes, Meldungen und Folgeaktionen, die basierend auf dem beobachteten Konfigurationszustand ausgeführt werden sollen.

Code	Nachricht	Aktion
Unbekannt	Unbekannter Fehler
HostUnreachable	Der Hostcomputer ist nicht erreichbar.	Überprüfen der Netzwerkkonnektivität der Verwaltung zwischen Netzwerkcontroller und Host
PAIpAddressExhausted	Die PA-IP-Adressen sind erschöpft	Erhöhen der IP-Poolgröße des logischen Subnetzes des HNV-Anbieters
PAMacAddressExhausted	Die PA-Ma.-Adressen sind erschöpft.	Vergrößern des Mac-Poolbereichs
PAAddressConfigurationFailure	Fehler beim Einfügen von PA-Adressen für den Host.	Überprüfen der Netzwerkkonnektivität der Verwaltung zwischen Netzwerkcontroller und Host.
CertificateNotTrusted	Das Zertifikat ist nicht vertrauenswürdig.	Korrigieren der Zertifikate, die für die Kommunikation mit dem Host verwendet werden.
CertificateNotAuthorized	Das Zertifikat ist nicht autorisiert.	Korrigieren der Zertifikate, die für die Kommunikation mit dem Host verwendet werden.
PolicyConfigurationFailureOnVfp	Fehler beim Konfigurieren von VFP-Richtlinien.	Dies ist ein Laufzeitfehler. Keine eindeutigen Problemumgehungen. Erfassen von Protokollen.
PolicyConfigurationFailure	Fehler beim Pushen von Richtlinien an die Hosts aufgrund von Kommunikationsfehlern oder anderen Fehlern im NetworkController.	Keine definitiven Aktionen. Dies ist auf Fehler bei der Verarbeitung des Zielzustands in den Netzwerkcontrollermodulen zurückzuführen. Erfassen von Protokollen.
HostNotConnectedToController	Der Host ist noch nicht mit dem Netzwerkcontroller verbunden.	Portprofil, das nicht auf dem Host angewendet wird, oder der Host ist vom Netzwerkcontroller nicht erreichbar. Überprüfen, ob der HostID-Registrierungsschlüssel mit der Instanz-ID der Serverressource übereinstimmt.
MultipleVfpEnabledSwitches	Es gibt mehrere VFp-fähige Switches auf dem Host.	Löschen eines der Switches, da der Host-Agent des Netzwerkcontrollers nur einen vSwitch mit aktivierter VFP-Erweiterung unterstützt.
PolicyConfigurationFailure	Fehler beim Pushen von VNet-Richtlinien für eine VMNic aufgrund von Zertifikat- oder Konnektivitätsfehlern.	Überprüfen, ob die richtigen Zertifikate bereitgestellt wurden (der Name des Zertifikatantragstellers muss mit dem FQDN des Hosts übereinstimmen). Außerdem überprüfen der Hostkonnektivität mit dem Netzwerkcontroller.
PolicyConfigurationFailure	Fehler beim Pushen von vSwitch-Richtlinien für eine VMNic aufgrund von Zertifikat- oder Konnektivitätsfehlern.	Überprüfen, ob die richtigen Zertifikate bereitgestellt wurden (der Name des Zertifikatantragstellers muss mit dem FQDN des Hosts übereinstimmen). Außerdem überprüfen der Hostkonnektivität mit dem Netzwerkcontroller.
PolicyConfigurationFailure	Fehler beim Pushen von Firewallrichtlinien für eine VM-Netzwerkschnittstellenkarte aufgrund von Zertifikat- oder Konnektivitätsfehlern.	Überprüfen, ob die richtigen Zertifikate bereitgestellt wurden (der Name des Zertifikatantragstellers muss mit dem FQDN des Hosts übereinstimmen). Außerdem überprüfen der Hostkonnektivität mit dem Netzwerkcontroller.
DistributedRouterConfigurationFailure	Fehler beim Konfigurieren der Einstellungen für den verteilten Router auf der Host-vNic.	TCPIP-Stapelfehler. Kann die Bereinigung der PA- und DR-Host-VNICs auf dem Server erfordern, auf dem dieser Fehler gemeldet wurde.
DhcpAddressAllocationFailure	Fehler bei der DHCP-Adresszuordnung für eine VMNic.	Überprüfen, ob das Attribut für die statische IP-Adresse für die NIC-Ressource konfiguriert ist.
CertificateNotTrusted CertificateNotAuthorized	Fehler beim Herstellen einer Verbindung mit MUX aufgrund von Netzwerk- oder Zertifikatfehlern.	Überprüfen des numerischen Codes im Fehlermeldungscode: Dies entspricht dem Winsock-Fehlercode. Zertifikatfehler sind präzise (z. B. das Zertifikat kann nicht überprüft werden, ist nicht autorisiert usw.)
HostUnreachable	MUX ist fehlerhaft (allgemeiner Fall ist, dass BGPRouter getrennt ist).	Der BGP-Peer auf dem RRAS-Switch (BGP-VM) oder Top-of-Rack (ToR) ist nicht erreichbar oder kann kein erfolgreiches Peering ausführen. Überprüfen der BGP-Einstellungen sowohl auf der Software Load Balancer Multiplexer-Ressource als auch auf dem BGP-Peer (ToR oder RRAS-VMs).
HostNotConnectedToController	Der SLB-Host-Agent ist nicht verbunden.	Überprüfen, ob der SLB-Host-Agent-Dienst ausgeführt wird. Überprüfen in den SLB-Host-Agent-Protokollen (automatische Ausführung), warum dies der Fall ist.Falls der SLBM (NC) das Zertifikat ablehnt, zeigt der Status des ausgeführten Host-Agents genauere Informationen an.
PortBlocked	Der VFP-Port wird aufgrund fehlender VNet-/ACL-Richtlinien blockiert.	Überprüfen Sie, ob andere Fehler vorliegen, die dazu führen können, dass die Richtlinien nicht konfiguriert werden.
Überlastung	Loadbalancer-MUX ist überladen.	Leistungsproblem mit MUX
RoutePublicationFailure	LoadBalancer-MUX ist nicht mit einem BGP-Router verbunden.	Überprüfen, ob die MUX mit den BGP-Routern verbunden und BGP-Peering ordnungsgemäß eingerichtet ist.
VirtualServerUnreachable	LoadBalancer-MUX ist nicht mit dem SLB-Manager verbunden.	Überprüfen der Konnektivität zwischen SLBM und MUX
QosConfigurationFailure	Fehler beim Konfigurieren von QOS-Richtlinien.	Überprüfen, ob genügend Bandbreite für alle VMs verfügbar ist, wenn QOS-Reservierung verwendet wird.

Überprüfen der Netzwerkkonnektivität zwischen dem Netzwerkcontroller und dem Hyper-V-Host (NC-Host-Agent-Dienst)

Führen Sie den netstat folgenden Befehl aus, um zu überprüfen, ob drei Verbindungen zwischen dem NC-Host-Agent und den Netzwerkcontrollerknoten und einem LISTENING Socket auf dem Hyper-V-Host vorhanden sindESTABLISHED.

• LAUSCHEN an Port TCP:6640 auf Hyper-V-Host (NC-Host-Agent-Dienst)
• Zwei eingerichtete Verbindungen von der Hyper-V-Host-IP-Adresse an Port 6640 mit der NC-Knoten-IP-Adresse an kurzlebigen Ports (> 32000)
• Eine eingerichtete Verbindung von der Hyper-V-Host-IP-Adresse am kurzlebigen Port mit der REST-IP-Adresse des Netzwerkcontrollers an Port 6640

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

Überprüfen der Host-Agent-Dienste

Der Netzwerkcontroller kommuniziert mit zwei Host-Agent-Diensten auf den Hyper-V-Hosts: SLB-Host-Agent und NC-Host-Agent. Es ist möglich, dass einer oder beide dieser Dienste nicht ausgeführt werden. Überprüfen Sie den Zustand der Dienste, und starten Sie sie neu, wenn sie nicht ausgeführt werden:

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Überprüfen Sie die Integrität des Netzwerkcontrollers.

Wenn keine drei ESTABLISHED Verbindungen vorhanden sind oder der Netzwerkcontroller nicht reagiert, überprüfen Sie, ob alle Knoten und Dienstmodule mit den folgenden Cmdlets ausgeführt werden.

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

Die Module des Netzwerkcontroller-Diensts sind:

• ControllerService
• ApiService
• SlbManagerService
• ServiceInsertion
• FirewallService
• VSwitchService
• GatewayManager
• FnmService
• HelperService
• UpdateService

Überprüfen Sie, ob ReplicaStatus das ist Ready und HealthState ist Ok.

In einer Produktionsbereitstellung mit einem Netzwerkcontroller mit mehreren Knoten können Sie auch überprüfen, für welchen Knoten jeder Dienst primär ist, und dessen einzelner Replikatstatus.

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

Stellen Sie sicher, dass der Replikatstatus für jeden Dienst „Bereit“ lautet.

Suchen nach entsprechenden HostIDs und Zertifikaten zwischen Netzwerkcontroller und jedem Hyper-V-Host

Führen Sie auf einem Hyper-V-Host die folgenden Cmdlets aus, um zu überprüfen, ob die HostID der Instanz-ID einer Serverressource auf dem Netzwerkcontroller entspricht.

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

Wartung

Aktualisieren Sie bei Verwendung von SDNExpress-Skripts oder manueller Bereitstellung den HostId-Schlüssel in der Registrierung so, dass er mit der Instanz-ID der Serverressource übereinstimmt. Starten Sie den Netzwerkcontroller-Host-Agent auf dem Hyper-V-Host (physischer Server) neu, Wenn Sie VMM verwenden, löschen Sie den Hyper-V-Server aus VMM, und entfernen Sie den Registrierungsschlüssel „HostId“. Fügen Sie dann den Server erneut über VMM hinzu.

Überprüfen Sie, ob die Fingerabdrücke der X.509-Zertifikate, die vom Hyper-V-Host (der Hostname ist der Antragstellername des Zertifikats) für die Kommunikation zwischen dem Hyper-V-Host (NC-Host-Agent-Dienst) und den Netzwerkcontrollerknoten verwendet werden, identisch sind. Überprüfen Sie außerdem, ob das REST-Zertifikat des Netzwerkcontrollers den Antragstellernamen hat CN=<FQDN or IP>.

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

Sie können auch die folgenden Parameter jedes Zertifikats überprüfen, um sicherzustellen, dass der Antragstellername erwartungsgemäß ist (Hostname oder NC REST FQDN oder IP), das Zertifikat noch nicht abgelaufen ist und dass alle Zertifizierungsstellen in der Zertifikatkette in der vertrauenswürdigen Stammzertifizierungsstelle enthalten sind.

• Antragstellername
• Ablaufdatum
• Vertrauenswürdig durch Stammautorität

Wenn mehrere Zertifikate denselben Antragstellernamen auf dem Hyper-V-Host haben, wählt der Netzwerkcontroller-Host-Agent zufällig einen aus, der dem Netzwerkcontroller angezeigt werden soll. Dies entspricht möglicherweise nicht dem Fingerabdruck der Serverressource, die dem Netzwerkcontroller bekannt ist. Löschen Sie in diesem Fall eines der Zertifikate mit demselben Antragstellernamen auf dem Hyper-V-Host, und starten Sie dann den Host-Agent-Dienst des Netzwerkcontrollers neu. Wenn immer noch keine Verbindung hergestellt werden kann, löschen Sie das andere Zertifikat mit demselben Antragstellernamen auf dem Hyper-V-Host, und löschen Sie die entsprechende Serverressource in VMM. Erstellen Sie dann die Serverressource in VMM neu, wodurch ein neues X.509-Zertifikat generiert und auf dem Hyper-V-Host installiert wird.

Überprüfen des SLB-Konfigurationsstatus

Der SLB-Konfigurationsstatus kann als Teil der Ausgabe an das Debug-NetworkController Cmdlet bestimmt werden. Dieses Cmdlet gibt auch den aktuellen Satz von Netzwerkcontrollerressourcen in JSON-Dateien, alle IP-Konfigurationen von jedem Hyper-V-Host (Server) und die lokale Netzwerkrichtlinie aus Host-Agent-Datenbanktabellen aus.

Standardmäßig werden weitere Ablaufverfolgungen erfasst. Um Ablaufverfolgungen nicht zu sammeln, fügen Sie den -IncludeTraces:$false Parameter hinzu.

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

Die Informationen zum SLB-Konfigurationsstatus finden Sie in der Datei diagnostics-slbstateResults.Json in diesem Verzeichnis.

Diese JSON-Datei kann in die folgenden Abschnitte aufgeteilt werden:

• Fabric
  • SlbmVips: In diesem Abschnitt wird die IP-Adresse der SLB-Manager-VIP-Adresse aufgeführt, die vom Netzwerkcontroller verwendet wird, um Konfiguration und Integrität zwischen den SLB-Muxes und SLB-Host-Agents zu koordinieren.
  • MuxState: In diesem Abschnitt wird ein Wert für jeden bereitgestellten SLB-Mux aufgelistet, der den Status des Mux angibt.
  • Routerkonfiguration: In diesem Abschnitt werden die autonome Systemnummer (ASN), die Transit-IP-Adresse und die ID des Upstreamrouters (BGP-Peer) aufgelistet. Außerdem werden die ASN und die Transit-IP-Adresse der SLB-Muxes aufgelistet.
  • Informationen zum verbundenen Host: In diesem Abschnitt wird die Verwaltungs-IP-Adresse aller Hyper-V-Hosts aufgeführt, die zum Ausführen von Workloads mit Lastenausgleich verfügbar sind.
  • VIP-Bereiche: In diesem Abschnitt werden die Bereiche des öffentlichen und privaten VIP-IP-Pools aufgeführt. Die SLBM-VIP wird als zugeordnete IP-Adresse aus einem dieser Bereiche eingebunden.
  • Mux-Routen: In diesem Abschnitt wird ein Wert für jeden bereitgestellten SLB-Mux aufgelistet, der alle Routenankündigungen für diesen bestimmten Mux enthält.
• Mandant
  • VipConsolidatedState: In diesem Abschnitt wird der Konnektivitätsstatus für jede Mandanten-VIP aufgeführt, einschließlich angekündigtem Routenpräfix, Hyper-V-Host und DIP-Endpunkten.

Gatewayüberprüfung

Vom Netzwerkcontroller:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Von Gateway-VM:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

Von oben im Rack (ToR) Schalter:

sh ip bgp summary (for 3rd party BGP Routers)

Windows BGP-Router:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Zusätzlich dazu scheint nach den bisherigen Erfahrungen (insbesondere bei SDNExpress-basierten Bereitstellungen) der häufigste Grund dafür, dass das Mandantendepot nicht auf GW-VMs konfiguriert wird, die Tatsache zu sein, dass die GW-Kapazität in „FabricConfig.psd1“ im Vergleich zu dem, was Benutzer versuchen, den Netzwerkverbindungen (S2S-Tunneln) in „TenantConfig.psd1“ zuzuweisen, geringer ist. Dies kann einfach überprüft werden, indem Die Ausgaben der folgenden Cmdlets verglichen werden:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hoster] Überprüfen der Datenebene

Nachdem der Netzwerkcontroller bereitgestellt, virtuelle Mandantennetzwerke und Subnetze erstellt und VMs an die virtuellen Subnetze angefügt wurden, können zusätzliche Tests auf Fabricebene vom Hoster durchgeführt werden, um die Mandantenkonnektivität zu überprüfen.

Überprüfen der logischen Netzwerkkonnektivität des HNV-Anbieters

Nachdem die erste Gast-VM, die auf einem Hyper-V-Host ausgeführt wird, mit einem virtuellen Mandantennetzwerk verbunden wurde, weist der Netzwerkcontroller dem Hyper-V-Host zwei IP-Adressen (PA-IP-Adressen) des HNV-Anbieters zu. Diese IP-Adressen stammen aus dem IP-Pool des logischen Netzwerks des HNV-Anbieters und werden vom Netzwerkcontroller verwaltet. So finden Sie heraus, was diese beiden HNV-IP-Adressen sind:

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Diese IP-Adressen des HNV-Anbieters (PA-IP-Adressen) werden Ethernet-Adaptern zugewiesen, die in einem separaten TCP/IP-Netzwerkdepot erstellt werden und verfügen über den Adapternamen VLANX, wobei „X“ das VLAN ist, das dem logischen Netzwerk des HNV-Anbieters (Transport) zugewiesen ist.

Die Konnektivität zwischen zwei Hyper-V-Hosts, die das logische Netzwerk des HNV-Anbieters verwenden, kann durch Ping mit einem zusätzlichen Depotparameter (-c Y) erfolgen, wobei „Y“ das TCP/IP-Netzwerkdepot ist, in dem die PAhostVNICs erstellt werden. Dieses Depot kann bestimmt werden, indem Sie Folgendes ausführen:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

Angenommen, die Hyper-V-Hosts 1 und 2 verfügen über die folgenden IP-Adressen des HNV-Anbieters (PA):

Hyper-V-Host	PA-IP-Adresse 1	PA-IP-Adresse 2
Host 1	10.10.182.64	10.10.182.65
Host 2	10.10.182.66	10.10.182.67

Mit dem folgenden Befehl können wir die logische Netzwerkkonnektivität des HNV-Anbieters mit einem Ping zwischen den beiden Hosts überprüfen.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Wartung

Wenn der Ping des HNV-Anbieters nicht funktioniert, überprüfen Sie Ihre physische Netzwerkkonnektivität einschließlich VLAN-Konfiguration. Die physischen NICs auf jedem Hyper-V-Host sollten sich im Trunkmodus befinden, ohne dass ein bestimmtes VLAN zugewiesen ist. Die vNIC des Verwaltungshosts sollte vom VLAN des logischen Verwaltungsnetzwerks isoliert werden.

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

Überprüfen der MTU- und Jumbo-Frame-Unterstützung im logischen HNV-Anbieternetzwerk

Ein weiteres häufiges Problem im logischen HNV-Anbieternetzwerk besteht darin, dass die physischen Netzwerkports und/oder Ethernet-Karten nicht über eine große MTU verfügen, die für die Verarbeitung des Overheads von VXLAN (oder NVGRE) Kapselung konfiguriert ist.

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

Verwenden Sie Test-LogicalNetworkSupportsJumboPacket das Cmdlet, um zu testen, ob das logische Netzwerk des HNV-Anbieters end-to-End die größere MTU-Größe unterstützt:

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

Wartung

• Anpassen der MTU-Größe für die Ports des physischen Switch auf mindestens 1674B (einschließlich 14B Ethernet-Header und -Trailer)
• Wenn Ihre NIC-Karte das Schlüsselwort "EncapOverhead" nicht unterstützt, passen Sie das Schlüsselwort JumboPacket auf mindestens 1674B an.

Überprüfen der Mandanten-VM-NIC-Konnektivität

Jede VM-NIC, die einer Gast-VM zugewiesen ist, verfügt über eine Zuordnung zwischen Kunden- und Anbieteradressen (CA-PA), also dem privaten Kundenadressraum (CA) und dem HNV-Anbieteradressraum (PA). Diese Zuordnungen werden in den OVSDB-Servertabellen auf jedem Hyper-V-Host gespeichert und können durch Ausführen des folgenden Cmdlets ermittelt werden.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

Mit diesen Informationen kann nun ein VM-Ping des Mandanten vom Hoster über den Netzwerkcontroller mithilfe des Test-VirtualNetworkConnection Cmdlets initiiert werden.

Spezifische Problembehandlungsszenarien

Die folgenden Abschnitte bieten Anleitungen für die Problembehandlung von spezifischen Szenarien.

Keine Netzwerkkonnektivität zwischen zwei Mandanten-VMs

1. [Mandant] Stellen Sie sicher, dass die Windows-Firewall auf Mandanten-VMs den Datenverkehr nicht blockiert.
2. [Mandant] Überprüfen Sie, ob dem virtuellen Mandantencomputer IP-Adressen zugewiesen wurden, indem Sie ausführen ipconfig.
3. [Hoster] Führen Sie Test-VirtualNetworkConnection den Hyper-V-Host aus, um die Konnektivität zwischen den beiden betreffenden virtuellen Mandantencomputern zu überprüfen.

Beispiel

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Erstellen Sie CA-Ping zwischen „Green Web VM 1“ mit senderCA-IP 192.168.1.4 auf Host „sa18n30-2.sa18.nttest.microsoft.com“ mit mgmt-IP 10.127.132.153 und ListenerCA-IP 192.168.1.5, die beide an das virtuelle Subnetz (VSID) 4114 angefügt sind.

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[Mandant] Überprüfen Sie, ob keine verteilten Firewallrichtlinien für das virtuelle Subnetz oder die VM-Netzwerkschnittstellen angegeben wurden, die den Datenverkehr blockieren würden.

Fragen Sie die Netzwerkcontroller-REST-API ab, die Sie in der Demoumgebung unter sa18n30nc in der Domäne sa18.nttest.microsoft.com finden.

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Sehen Sie sich die IP-Konfiguration und virtuelle Subnetze an, die auf diese ACL verweisen

1. [Hoster] Führen Sie Get-ProviderAddress auf beiden Hyper-V-Hosts aus, die die beiden betreffenden Mandanten-VMs hosten, und führen Sie dann Test-LogicalNetworkConnection oder ping -c <compartment> vom Hyper-V-Host aus, um die Konnektivität im logischen Netzwerk des HNV-Anbieters zu überprüfen.
2. [Hoster] Stellen Sie sicher, dass richtige MTU-Einstellungen auf den Hyper-V-Hosts und auf allen Switches der Ebene 2 festgelegt sind, die sich zwischen den Hyper-V-Hosts befinden. Führen Sie Test-EncapOverheadValue auf allen betreffenden Hyper-V-Hosts aus. Stellen Sie außerdem sicher, dass für alle Switches der Ebene 2 zwischen den Hosts der MTU-Wert mindestens auf 1.674 Byte festgelegt ist, um den maximalen Mehraufwand von 160 Byte zu berücksichtigen.
3. [Hoster] Wenn PA-IP-Adressen nicht vorhanden sind und/oder die CA-Konnektivität unterbrochen ist, überprüfen Sie, ob die Netzwerkrichtlinie empfangen wurde. Überprüfen Sie durch eine Ausführung von Get-PACAMapping, ob die Kapselungsregeln und die Zuordnungen zwischen Anbieter- und Kundenadressen, die zum Erstellen virtueller Overlaynetzwerke erforderlich sind, ordnungsgemäß eingerichtet sind.
4. [Hoster] Vergewissern Sie sich, dass der Host-Agent des Netzwerkcontrollers mit dem Netzwerkcontroller verbunden ist. Führen Sie hierzu netstat -anp tcp |findstr 6640 aus.
5. [Hoster] Überprüfen Sie, ob die Host-ID in HKLM/ mit der Instanz-ID der Serverressourcen übereinstimmt, die die Mandanten-VMs hosten.
6. [Hoster] Überprüfen Sie, ob die Portprofil-ID mit der Instanz-ID der VM-Netzwerkschnittstellen der MandantenVMs übereinstimmt.

Protokollierung, Ablaufverfolgung und erweiterte Diagnose

Die folgenden Abschnitte enthalten Informationen zur erweiterten Diagnose, Protokollierung und Ablaufverfolgung.

Zentrale Protokollierung des Netzwerkcontrollers

Der Netzwerkcontroller kann Debuggerprotokolle automatisch erfassen und an einem zentralen Speicherort speichern. Die Protokollsammlung kann aktiviert werden, wenn Sie den Netzwerkcontroller zum ersten Mal bereitstellen oder zu jedem beliebigen späteren Zeitpunkt. Die Protokolle werden vom Netzcontroller und den vom Netzcontroller verwalteten Netzwerkelementen erfasst: Hostcomputer, Software Load Balancer (SLB) und Gatewaycomputer.

Diese Protokolle umfassen Debugprotokolle für den Netzwerkcontrollercluster, die Netzwerkcontrolleranwendung, Gatewayprotokolle, SLB, virtuelle Netzwerke und die verteilte Firewall. Wenn dem Netzwerkcontroller ein neues Host-/SLB-/Gatewayelement hinzugefügt wird, wird die Protokollierung auf diesen Computern gestartet. Wenn ein Host-/SLB-/Gatewayelement vom Netzwerkcontroller entfernt wird, wird die Protokollierung auf diesen Computern entsprechend beendet.

Aktivieren der Protokollierung

Die Protokollierung wird automatisch aktiviert, wenn Sie den Netzwerkcontrollercluster mithilfe des Install-NetworkControllerCluster Cmdlets installieren. Standardmäßig werden die Protokolle lokal auf den Netzwerkcontrollerknoten unter %systemdrive%\SDNDiagnostics gesammelt. Es wird empfohlen, diesen Speicherort als Remotedateifreigabe (nicht lokal) zu ändern.

Die Netzwerkcontroller-Clusterprotokolle werden unter %programData%\Windows Fabric\log\Traces gespeichert. Sie können einen zentralen Speicherort für die Protokollsammlung mit dem DiagnosticLogLocation Parameter mit der Empfehlung angeben, dass dies auch eine Remotedateifreigabe ist.

Wenn Sie den Zugriff auf diesen Speicherort einschränken möchten, können Sie die Zugriffsanmeldeinformationen mit dem LogLocationCredential Parameter angeben. Wenn Sie die Anmeldeinformationen für den Zugriff auf den Protokollspeicherort angeben, sollten Sie auch den Parameter angeben, der CredentialEncryptionCertificate zum Verschlüsseln der lokal auf den Netzwerkcontrollerknoten gespeicherten Anmeldeinformationen verwendet wird.

Bei den Standardeinstellungen wird empfohlen, dass Sie für einen Netzwerkcontrollercluster mit drei Knoten mindestens 75 GB freien Speicherplatz am zentralen Speicherort und 25 GB auf den lokalen Knoten vorsehen (wenn Sie keinen zentralen Speicherort verwenden).

Ändern der Protokollierungseinstellungen

Sie können die Protokollierungseinstellungen jederzeit mit dem Cmdlet Set-NetworkControllerDiagnostic ändern. Die folgenden Einstellungen können geändert werden:

• Zentraler Protokollspeicherort.

  Sie können den Speicherort zum Speichern aller Protokolle mit dem DiagnosticLogLocation-Parameter ändern.

• Anmeldeinformationen für den Zugriff auf den Protokollspeicherort.

  Sie können die Anmeldeinformationen für den Zugriff auf den Protokollspeicherort mit dem LogLocationCredential-Parameter ändern.

• Wechseln zur lokalen Protokollierung.

  Wenn Sie einen zentralen Speicherort für die Protokolle angegeben haben, können Sie mit dem Parameter UseLocalLogLocation zur lokalen Protokollierung auf den Netzwerkcontrollerknoten zurückkehren (wegen des großen Speicherplatzbedarfs nicht empfohlen).

• Protokollierungsbereich.

  Standardmäßig werden alle Protokolle erfasst. Sie können den Bereich so ändern, dass nur Netzwerkcontroller-Clusterprotokolle erfasst werden.

• Protokolliergrad.

  Die Standardprotokollierungsebene ist „Information“. Sie können sie in „Fehler“, „Warnung“ oder „Ausführlich“ ändern.

• Protokollalterungszeit.

  Die Protokolle werden im Umlaufverfahren gespeichert. Standardmäßig verfügen Sie über drei Tage Protokolldaten, unabhängig davon, ob Sie lokale Protokollierung oder zentrale Protokollierung verwenden. Sie können dieses Zeitlimit mit dem LogTimeLimitInDays Parameter ändern.

• Protokollalterungsgröße.

  Standardmäßig verfügen Sie über maximal 75 GB Protokolldaten, wenn Sie zentrale Protokollierung verwenden, und 25 GB bei Verwendung lokaler Protokollierung. Sie können diesen Grenzwert mit dem LogSizeLimitInMBs Parameter ändern.

Sammeln von Protokollen und Ablaufverfolgungen

VMM-Bereitstellungen verwenden standardmäßig zentrale Protokollierung für den Netzwerkcontroller. Der Dateifreigabe-Speicherort für diese Protokolle wird beim Bereitstellen der Vorlage des Netzwerkcontroller-Diensts angegeben.

Wenn kein Dateispeicherort angegeben wurde, wird die lokale Protokollierung auf jedem Netzwerkcontrollerknoten mit Protokollen verwendet, die unter "C:\Windows\tracing\SDNDiagnostics" gespeichert sind. Diese Protokolle werden in der folgenden Hierarchie gespeichert:

• CrashDumps
• NCApplicationCrashDumps
• NCApplicationLogs
• PerfCounters
• SDNDiagnostics
• Traces

Der Netzwerkcontroller verwendet (Azure) Service Fabric. Service Fabric-Protokolle sind möglicherweise erforderlich, wenn bestimmte Probleme behoben werden. Diese Protokolle finden Sie auf jedem Netzwerkcontrollerknoten unter C:\ProgramData\Microsoft\Service Fabric.

Wenn ein Benutzer das Debug-NetworkController Cmdlet ausgeführt hat, stehen weitere Protokolle auf jedem Hyper-V-Host zur Verfügung, der mit einer Serverressource im Netzwerkcontroller angegeben wurde. Diese Protokolle (und Ablaufverfolgungen, falls aktiviert) werden unter C:\NCDiagnostics gespeichert.

SLB-Diagnose

SLBM-Fabric-Fehler (Hostingdienstanbieteraktionen)

1. Überprüfen Sie, ob Software Load Balancer Manager (SLBM) funktioniert und die Orchestrierungsebenen miteinander kommunizieren können: SLBM -> SLB Mux und SLBM -> SLB-Host-Agents. Führen Sie DumpSlbRestState von einem beliebigen Knoten mit Zugriff auf den REST-Endpunkt des Netzwerkcontrollers aus.
2. Überprüfen Sie die SDNSLBMPerfCounters in PerfMon auf einem der VMs des Netzwerkcontrollerknotens (vorzugsweise den primären Netzwerkcontrollerknoten - Get-NetworkControllerReplica):
   1. Ist die Load Balancer-Engine (LB) mit SLBM verbunden? (SLBM LBEngine-Konfigurationen Insgesamt > 0)
   2. Kennt SLBM zumindest die eigenen Endpunkte? (VIP-Endpunkte gesamt>= 2)
   3. Sind Hyper-V-Hosts (DIP) mit SLBM verbunden? (Verbundene HP-Clients == Anzahl Server)
   4. Ist SLBM mit Muxes verbunden? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
3. Stellen Sie sicher, dass der konfigurierte BGP-Router erfolgreich mit dem SLB MUX peering.
   1. Bei Verwendung von RRAS mit Remotezugriff (d. h. BGP-VM):
      1. Get-BgpPeer sollte verbunden angezeigt werden.
      2. Get-BgpRouteInformation sollte mindestens eine Route für die SLBM self VIP anzeigen.
   2. Wenn Sie den physischen Top-of-Rack (ToR)-Schalter als BGP-Peer verwenden, lesen Sie Ihre Dokumentation:
      1. Beispiel: # show bgp instance
4. Überprüfen Sie die SlbMuxPerfCounters- und SLBMUX-Zähler in PerfMon auf der SLB-Mux-VM.
5. Überprüfen Sie den Konfigurationsstatus und VIP-Bereiche in der Ressource "Software Load Balancer Manager".
   1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (überprüfen Sie VIP-Bereiche in IP-Pools, und stellen Sie sicher, dass sich SLBM self-VIP (LoadBalanacerManagerIPAddress) und alle mandantenorientierten VIPs in diesen Bereichen befinden)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
   2. Debug-NetworkControllerConfigurationState -

Wenn eine der oben genannten Überprüfungen fehlschlägt, befindet sich auch der SLB-Zustand des Mandanten in einem Fehlermodus.

Wartung

Beheben Sie basierend auf den folgenden angezeigten Diagnoseinformationen Folgendes:

• Stellen Sie sicher, dass SLB-Multiplexer verbunden sind.
  • Beheben von Zertifikatproblemen
  • Beheben von Netzwerkverbindungsproblemen
• Sicherstellen, dass BGP-Peeringinformationen erfolgreich konfiguriert wurden.
• Stellen Sie sicher, dass die Host-ID in der Registrierung mit der Serverinstanz-ID in der Serverressource übereinstimmt (weitere Informationen finden Sie im Anhang unter dem Fehlercode HostNotConnected).
• Erfassen von Protokollen

SLBM-Mandantenfehler (Hostingdienstanbieter und Mandantenaktionen)

1. [Hoster] Überprüfen Sie Debug-NetworkControllerConfigurationState , ob sich LoadBalancer-Ressourcen in einem Fehlerzustand befinden. Versuch, das Problem anhand der Tabelle mit den Aktionspunkten im Anhang zu entschärfen.
   1. Überprüfen Sie, ob ein VIP-Endpunkt vorhanden ist und Anzeigenrouten.
   2. Überprüfen Sie, wie viele DIP-Endpunkte für den VIP-Endpunkt ermittelt wurden.
2. [Mandant] Die Überprüfung der Lastenausgleichsressourcen ist ordnungsgemäß angegeben.
   1. Überprüfen Sie DIP-Endpunkte, die in SLBM registriert sind, hosten virtuelle Mandantencomputer, die den IP-Konfigurationen des LoadBalancer-Back-End-Adresspools entsprechen.
3. [Hoster] Wenn DIP-Endpunkte nicht erkannt werden oder nicht verbunden sind:

   1. Überprüfen von Debug-NetworkControllerConfigurationState

      Überprüfen Sie, ob NC und SLB Host Agent erfolgreich mit dem Network Controller Event Coordinator verbunden sind.netstat -anp tcp |findstr 6640)

   2. Check HostIdin nchostagent service regkey (Verweisfehlercode HostNotConnected im Anhang) entspricht der Instanz-ID der entsprechenden Serverressource (Get-NCServer |convertto-json -depth 8).

   3. Überprüfen Sie die Portprofil-ID für den portierenden virtuellen Computer mit der Instanz-ID der NIC-Ressource des virtuellen Computers.

4. [Hostinganbieter] Protokolle sammeln.

SLB-Mux-Ablaufverfolgung

Informationen aus den Software Load Balancer-Muxes können auch über die Ereignisanzeige bestimmt werden.

1. Wählen Sie "Analyse- und Debugprotokolle anzeigen" im Menü Ereignisanzeige Ansicht aus.
2. Navigieren Sie zu "Anwendungen und Dienste protokolliert>Microsoft>Windows>SlbMuxDriver>Trace" in Ereignisanzeige.
3. Klicken Sie mit der rechten Maustaste darauf, und wählen Sie "Protokoll aktivieren" aus.

VFP- und vSwitch-Ablaufverfolgung

Von jedem Hyper-V-Host, der eine Gast-VM hostet, die an ein virtuelles Mandantennetzwerk angefügt ist, können Sie eine VFP-Ablaufverfolgung erfassen, um zu ermitteln, wo Probleme liegen könnten.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes